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A few years ago it was recognized that the vision of a truly low-cost, low-power radio-based cable 
replacement was feasible. Such a ubiquitous link would provide the basis for portable devices to 
communicate together in an ad hoc fashion by creating personal area networks which have similar 
advantages to their office environment counterpart - the local area network (LAN). Bluetooth is an 
effort by a consortium of companies to design a royalty free technology specification enabling this 
vision. This article describes the vision and goals of the Bluetooth program and introduces the 
radio-based technology. 



I. Vision 




link In recent years, wireless connectivity has been an active 
area of research as we have witnessed a large number of gov- 
ernment and industry initiatives, research efforts and standard 
activities that have aimed at enabling wireless and mobile net- 
working technologies. As a result, today we have a diverse 
set of wireless access technologies from satellite networks, to 
wide area cellular systems, and from wireless local loop and 
PCS to wireless LANs. However, most of these solutions tar- 
get narrow and specific application scenarios. With all such 
efforts spent on wireless link technologies, we still lack a uni- 
versal framework that offers a way to access information based 
on a diverse set of devices (e.g.. PDAs, mobile PCs. phones, 
pagers, etc.) in a seamless, user-friendly and efficient manner, 
brings computing, consortium 

Formed in February 1998 by mobile telephony and comput- 
ing leaders Ericsson. IBM, Intel. Nokia, and Toshiba, the Blue- 
tooth special interest group (SIC) is designing a royalty-free, 
technology specification where each of the founding compa- 
nies has a significant stake in enabling this vision. We believe 
that Bluetooth can revolutionize wireless connectivity for per- 
sonal and business mobile devices, enabling seamless voice 
and data communication via short-range radio links and allow- 
ing users to connect a wide range of devices easily and quickly, 
without the need for cables, expanding communications capa- 
bilities for mobile computers, mobile phones and other mobile 
devices, both inside and outside of the office. Considering a 
wide range of computing and communication devices such as 
PDAs, notebook computers, pagers, and cellular phones with 
different capabilities, we envisage Bluetooth to provide a solu- 
tion for access to information and personal communication by 
enabling a collaboration between devices in proximity of each 
other where every device provides its inherent function based 
on its user interface, form factor, cost and power constraints. 
Furthermore, the Bluetooth technology enables many new us- 
age models for portable devices. For notebook computer man- 
ufacturers, the development of a short-range radio frequency 



(RF) solution enables the notebook computer to connect to 
different varieties of cellular phones and other notebook com- 
puters. For cellular handset manufacturers, the RF solution re- 
moves many of the wires required for audio and data exchange. 
Wireless hands-free kits operate even while the cellular phone 
is stored in a purse. As an example for a new usage model, we 
enable a connection from a mobile computer to the Internet 
using a cellular phone as a bridge. In some cases, eveh when 
the cellular phone is stored out of plainsight inside a briefcase, 
for example. In this scenario, the connection to the Internet is 
automatically established and auto-con figured without! requir- 
ing a conscious effort on the user's part to connect the mobile 
computer to the cellular phone and configure these two devices 
to communicate. We refer to this as a hidden computing or an 
unconscious connectivity model that is a powerful paradigm 
for new and exciting applications. 

A very key characteristic of Bluetooth that differentiates it 
from other wireless technologies is that it enables combined 
usability models based on functions provided by different de- 
vices. Let us consider a connection between a PDA (comput- 
ing device) and a cellular phone (communicating device) using 
Bluetooth and a second connection between the cellular phone 
and a cellular base station providing connectivity for both data 
and voice communication. In this model, the PDA maintains 
its function as a computing device and the phone maintains its 
role as a communication device - each one of these devices 
provide a specific function efficiently, yet their function is sep- 
arate and each can be used independently of the other. How- 
ever, when these devices are near each other they provide a 
useful combined function. We believe that this function and 
connectivity model based on a combination of wireless access 
technologies - each matched to different device capabilities 
and requirements - is a powerful paradigm that will enahle 
ubiquitous and pervasive wireless communication. Manv of 
these wireless link technologies are available today, however 
there is a need to provide a wireless connectivity, network- 
in", and application framework to realize ihe total solution. 
This is exactly the charter of the Bluetooth SIG. In addition 
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10 combining the resources of a personal network, (he RF link- 
could also connect the personal network lo the wired infras- 
tructure. A data access point in an office, conference room, or 
airport kiosk would act as an information gatewav for a note- 
book computer or cellular handset. 

The remainder of this paper is organized as follows. Sec- 
tion II describes the goals the Bluetooth SIG hopes to achieve. 
Section III provides an overview of the Bluetooth architecture 
as it currently exists. Section IV compares the Bluetooth SIG 
to other industry initiatives involving wireless technology and 
Section V summarizes the article. 

II. Goals 

II.A. New Usage Models 

The Bluetooth SIG is attempting to enable new usage models 
and create additional benefits for users of portable telephony 
and computer products. In addition to the examples presented 
in Section I. the SIG wants to enable the following future pos- 
sibilities. 

• The Three-in-One Phone. In this scenario, you are able 
to use the same phone wherever you are. When you're at 
the office, your phone functions as an intercom (no tele- 
phony charge). At home, it functions as a portable phone 
(fixed line charge). And when you're outdoors, the phone 
functions as a mobile phone (cellular charge). 

• The Briefcase Trick. Use e-mail while your notebook is 
still in the briefcase. When your notebook receives an 
e-mail, you'll get an alert on your mobile phone. You 
can also browse all incoming e-mails and read those you 
select in the mobile phone's window. 

• The Automatic Synchronizer. Automatic background syn- 
chronization keeps you up-to-date. Automatic synchro- 
nization of data on your desktop, notebook, personal dig- 
ital assistant! PDA), and mobile phone. For instance, as 
soon as you enter your office the address list and calendar 
in your notebook will automatically be updated to agree 
with the one in your desktop, or vice versa. Collect a 
business card on your phone and add it to your address 
list on your notebook PC. 

II.B. System Challenges 

The usage models described above require various system re- 
quirements to be met. In this section, we review several re- 
quirements and the challenges they offer. 

Support for both voice ami data. The air protocol must sup- 
port good quality real-lime voice, where "good" is considered 
10 be wired phone line quality. Voice quality is important to 
both end-users who are accustomed to it. and for speech recog- 
nition engines whose accuracy depends on it. 

Able to establish ad hoc connections. The dynamic nature of 
mobility makes it difficult to make any assumptions about the 
operating environment. Bluetooth units must be able to de- 
tect other compatible units and establish connections to (hem. 
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A single unit must be able to establish multiple connections in 
addition to accepting new connections while connected. Ignor- 
ing a new connection requests while connected is confusing to 
the user and deemed unacceptable, especially if we want to 
support unconscious computing while reiainingthe ability to 
perform interactive operations! r f 

Able to withstand interference from other sources in an unli- 
cenced band. The Bluetooth radio operates in ihe unlicensed 
2.4 GHz band where many other RF radiators are expected 
to exist. The fact that microwave ovens operating at-this fre- 
quency is one reason why this band is unlicensed in most coun- 
tries. The challenge is to avoid significant degradation in per- 
formance when other RF radiators, including other personal 
area networks in nearby use. are in operation. 

Worldwide use. Not only are "standard" cables equipped 
with a variety of connectors, different standards exists in dif- 
ferent geographical locations throughout the world. Experi- 
enced mobile travelers are accustomed to carrying around a 
number of different power, phone, and network connectors. 
The challenge here is very regulatory in nature with many gov- 
ernments having their own set of restrictions on RF technol- 
ogy. And while the 2.4 GHz band is unlicensed through most 
parts of the world, it varies in range and offset in a number of 
different countries. 

Similar amount of protection compared to a cable. In addi- 
tion to the radio's short-range nature and spread spectrum tech- 
niques, Bluetooth link protocols also provide authentication 
and privacy mechanisms. Users certainly don't want others 
listening in on their conversations, snooping their data trans- 
missions, or using their cellular phones for Internet access. 

Small size to accommodate in fey rat ion inio a variety of de- 
vices. The Bluetooth radio module must be small enough to 
permit integration into portable devices- Wearable devices in 
particular, such as mobile phones, headsets, and smart badges 
have little space to spare for a radio module. 

Negligible power consumption compared with the device in 
which the radio is used. Many Bluetooth devices will be bat- 
tery powered. This requirement implies the integration of the 
Bluetooth radio should not significantly compromise the bat- 
tery lifetime of the device. 

Encourage ubiquitous deployment of the technology. To 
achieve this goal, the SIG is designing an open specification 
defining the- radio, physical, link, and higher level protocols 
and services necessary to support the usage models in the vi- 
sion. The Specification will he made available under favorable 
adoption terms, including royalty free, to SIG members. 

II.C. The Specification 

The Bluetooth Specification defines the requirements ensur- 
ing interoperable operation between Bluetooth devices from 
different manufacturers. The Bluetooth Specification is work- 
in-progress and any material presented here is preliminary and 
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Figure I: Application Framework 

subject to change without notice. 1 The Specification draft is 
composed of two sets of documents: the radio and protocol 
definitions, and the compliance requirements. 

Figure 1 outlines the application framework in the context 
of the radio and protocol stack. The Radio takes care of send- 
ing and receiving modulated bitstreams. The Baseband (BB) 
protocol defines the timing, framing, packets, and How control 
on the link. The Link Manager (LM) assumes the responsibil- 
ity of managing connection states, enforcing fairness among 
slaves, power management, and other management tasks. The 
Logical Link Control handles multiplexing of higher level pro- 
tocols, segmentation and reassembly of large packets, and de- 
vice discovery. Audio data is mapped directly on to the Base- 
band while audio control is layered above the logical link con- 
trol. Above the data link layer, RFCOMM and network level 
protocols provide different communication abstractions. RF- 
COMM provides serial cable emulation using a subset of the 
ETS1 GSM 07.10 standard |2|. Other parts of the Bluetooth 
Specification deal with interoperability wilh other protocols 
and protocol slacks. Defining TCP/IP over Bluetooth requires 
that bridging, address resolution, MTU definition, and mul- 
ticast/broadcast mappings be solved. To accelerate the num- 
ber of w ireless-specilic applications, the Bluetooth SIG is con- 
templating interoperability with higher layer lrDA : and Vv'AP ; 
protocol slacks. 4 For example. IrOBEX |4| defines ;i iranspon- 
mdependent format and session protocol for object exchange 
and is used as the basis for a variety of applications from 
exchanging files and business cards to synchronizing address 
book and calendar schedules. 

The compliance requirements section of the Specification 
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Figure 2: Scatternet Example 

defines the radio and protocol 'features that are required for 
different classes of devices. Due to the wide variety of possible 
Bluetooth devices, different sets of requirements are needed. 
For example, one would not expect an audio headset to have 
the same minimum requirements as a notebook computer. The 
goal of the Specification's compliance section is ensuring that 
any device wearing a Bluetooth "logo" supports a minimum 
set of benefits for its user. 

III. The Bluetooth Architecture 

Bluetooth has been specified and designed with emphasis on 
robustness and low cost. Its implementation is based on a 
high-performance, yet low cost, integrated radio transceiver. 
Bluetooth is targeted at mobile and business users who need 
to establish a link, or small network, between their computer, 
cellular phone and other peripherals. The required and nom- 
inal range of Bluetooth radio is thus set to 10 meters (with 0 
dBm output power). To support other uses, for example the 
home environment, the Bluetooth chipset can be augmented 
with an external power amplifier to extend the range (up to 
100m with +20dBm output power). Auxiliary baseband hard- 
ware to support, for example, four or more voice channels can 
also be added. These additions to the base chip set are fully 
compatible with the nominal specification and may be added 
depending on the application. 

Bluetooth operates in the international 2.4 GHz ISM band, 
at a gross data rale of 1 Mbit/second, and features low eneriiv 
consumption for use in battery operated devices. Bluetooth 
uses an ad hoc. piconer structure hereafter referred to as vr<//- 
temet. Figure 2 illustrates an example scatternet. with one unit 
participating in both piconets. With the scaiternet technology 
described later in this document, it has been possible to achieve 
an aggregate throughput of over 10 M hi is/second or 20-voice 
channels within a fully expanded scalterncl. The structure also 
makes it possible to extend the radio range by simply addinu 
additional Bluetooth units acting as bridges at strategic places^ 
A single unit can support a maximum data transfer rate of 
721 kbits/second or a maximum of 3 voice channels. A mix- 
lure of voice and data transfer is also pos.sible in order lo sup- 
port multimedia applications. A robusi voice coding scheme 
with a rale of 64kbits/second per voice channel is used. To 
sustain these iransler rates in busy radio environment, u packet 
switching protocol with frequency hopping antl advanced cod- 
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ihg techniques are employed, It should also be mentioned that 
the Bluetooth features a graceful degradation of both voice and 
data transfer rates in busy RF environments. 

III.A. Master/Slave definitions 

In the Bluetooth network all units are peer units with identi- 
cal hardware and software interfaces distinguished by a unique 
48-bit address. At the start of a connection.^ initializing unit 
is temporarily assigned as a master. This assignment is valid 
only during this connection. It is the master which initiates the 
connection and controls the traffic on the connection. Slaves 
are assigned a temporary 3-bit member address to reduce the 
number of addressing bits required for active communication. 



III.B. Network topology 

The Bluetooth network supports both point-to-point and point- 
to-multipoint connections. A piconet is the network formed by 
a master and one or more slaves. Each piconet is defined by a 
different frequency hopping channel. AH units participating in 
the same piconet are synchronized to this channel. 

III.C. Robust Air Protocol and Adaptive Range 

To achieve the highest possible robustness for noisy radio en- 
vironments, Bluetooth uses a packet-switching protocol based 
on a frequency hop scheme with 1600 hops per second. The 
entire available frequency spectrum is used with 79 hops of 1 
MHz bandwidth, defined analogous to the IEEE 802. 1 I stan- 
dard [3|. This frequency hopping gives a reasonable band- 
width and the best interference immunity by utilizing the entire 
available spectrum of the open 2.4 GHz Industrial. Scientific, 
and Medical (ISM) hand. Virtual channels arc defined using 
pseudo-random hop sequences. 

The frequency hopping scheme is combined with fast Au- 
tomatic Repeat Request (ARQ). cyclic redundancy checks 
(CRC), and Forward Error Correction (FEC) for data. For 
voice a continuous variable slope delta modulation (CVSD) 
scheme is used. All of this results in a very robust link for 
both data and voice. 

To save power and minimize radio interference problems, 
a RSSI (Received Signals Strength Indicator) with a 72 dB 
dynamic range will be employed. The RSSI will measure the 
signal received from different units and adapt the RF output 
power to the exact requirement in each instance. That is, with 
a mouse or headset, the output power could be limited to a I m 
range, whereas a handset may need a range of 100 m or more. 

III.D. Establishing network connections 

When first establishing a network or adding components to a 
piconet. the units must be identified. Units can be dynamically 
connected and disconnected from the piconet at any time. Two 
available options lead to connection times of typically 0.64 and 
I.2X seconds respectively. This applies when the unit address 
is known and not more than about 5 hours have elapsed since 
the previous connection. A unit does not need to be connected 
at all times since only a typical delay of under one second is 
required to start a transaction. Hence, when not in use. the unit 
can be in a sleep stale (STANDBY) most of the time where 
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only a Low Power Oscillator (LPO) is running. This is. of 
course, beneficial for battery operation. 

Before any connections are made, all units are in standby 
mode. In this mode, an unconnected unit will onlv listen to 
messages every 1.28 seconds or 2.56 seconds depending on 
the selected option. Each time a unit wakes up. it will listen on 
one of 32 hop frequencies defined for this unit. 

The connect procedure is initiated by one of the units, the 
master. A connection is made either by a PAGE message if 
the address is already known, or by the INQUIRY message 
followed by a subsequent PAGE message if the address is un- 
known. In the initial PAGE state, the paging unit (which is the 
master) will send a train of 16 identical page messages on 16 
different hop frequencies defined for the unit to be paged (the 
slave). The train covers half the sequence of frequencies in 
which the slave can wake up. It is repeated 12S or 256 times 
( 1.28 or 2.56 seconds) depending on the needs of the paced 
unit. If no response is received after this time, the master trans- 
mits a train of 16 identical page messages on the remaining 16 
hop frequencies in the wake-up sequence. The maximum de- 
lay before the master reaches the slave is 2 times 1.28 seconds 
or 2.56 seconds if a periodicity of 1 .28 seconds was chosen for 
paging and 5. 12 seconds with 2.56 seconds periodicity respec- 
tively. This allows devices to trade off between access delay 
and standby power savings. 

The hop frequencies in the first page train are based on the 
master s slave clock estimate. The train will include the esti- 
mated wake-up hop, and 8 hops before and 7 hops after this 
hop. As a result, the estimate can be ± 7 hops in error and still 
the master reaches the slave with the first page train. Because 
the estimate is updated at each connection establishment, the 
acquisition delay is shorter when a shorter time has elapsed 
since the units were last connected. With a Low Power Oscil- 
lator (LPO) inaccuracy better than ± 250 ppm. the first train is 
still valid after at least 5-hours lapse with no connection. 

That is, for a time period of at least 5 hours since the last 
connection, the average acquisition times are 0.64 seconds and 
1.28 seconds respectively. If the first train does not cover the 
slave's wakcup frequency, the second train does and the aver- 
age acquisition delays are 1 .92 seconds and 3.84 seconds. 

The INQUIRY message is typically used for finding pub- 
he printers, faxes and similar equipment with an unknown ad- 
dress. The INQUIRY message is very similar to the page mes- 
sage but may require one additional train period to collect all 
the responses. 

If no data needs to be transmitted, the units may be put on 
HOLD where only an internal timer is running. When units 
go out of HOLD mode data transfer can be restarted instanta- 
neously. Units may thus remain connected, without data trans- 
fer, in a low power mode. The HOLD is typically used when 
connecting several piconets. It could also be used for units 
where data needs to be sent very infrequently and low power 
consumption is important. A typical application would be a 
room thermostat which may need to transfer data onlv once 
every minute. 

Two more low power modes are available, the SNIFF mode 
and the PARK mode. If we list the modes in increasing order 
of power efficiency, then the SNIFF mode has the hiuher duty 
cycle, followed by the HOLD mode with a lower duty cycle, 
and finishing with the PARK mode with the lowest dutv c'vcle! 
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Figure 3 describes the various possible connection stales. 



>» 

Q. 
C 

a 

UJ 

~j 

CO 

I 

CO 
ill 
GO 



Unconnected 
Standby 



Connecting 
Slates 



ltx|inr\ 
I lunkiuiun ' 



/ 

..-/ 



master uses this link 10 address the same slave at regular inter- 
vals, it becomes a synchronous link. The ACL link supports 
both symmetric and asymmetric modes. In addition, modes 
have been detined with or without FEC. anil with or without 
CRC and ARQ. 

III.F. Packet Definition 

A packet {sec Figure 4 consists of three fields: a 72-bit access 
code, a 54-bit header, and a payload of variable length (2-342 
bytes). Packets may consist of the (shortened) access code 
only, the access code and the header, or the access code, header 
and payload. 
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Figure 3: Connection State Machine 
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III.E. Link types 

Once a Bluetooth unit has been connected to a piconet it may 
communicate by means of two link types. That is. between 
any two members of the piconet forming a master-slave pair. 
Two link types are supported. These links are: 

• Synchronous Connection Oriented (SCO) link 

• Asynchronous (or isochronous) Connectionless (ACL) 
link. 

Different link types may apply between different master-slave 
pairs of the same piconet and the link type may change arbi- 
trarily during a session. The link type defines what type of 
packets can be used on a particular link. On each link type. 16 
different packet types can he used. The packets differ in func- 
tion and data bearing capabilities. For full duplex transmis- 
sions a Time Division Duplex scheme is used. Each packet is 
transmit ted in a different hop channel than the previous packet. 

An SCO link is a point-to-point full-duplex link between the 
master and a slave. This link is established once by the master 
and kept alive until being re leased.by the master The SCO link 
is typically used for a voice connection. The master reserves 
the slots used for the SCO link on the channel. 

The ACL link makes a momentary connection between the 
master and any of the slaves for the duration of one frame 
( inastei -to-slave slot and slave-to-master slot). No slots are re- 
served. The master can freely decide which slave to address 
and in which order. The member subaddress in the packet 
header determines the slave. A polling scheme is used to con- 
trol the traffic from the slaves to the master. The link is in- 
tended for asynchronous or isochronous data. However, if the 



Figure 4: Typical packet format 

The packet starts with a 72-bit channel access code. This 
access code is used for synchronization. DC offset compensa- 
tion and identification. The access code identifies all packets 
exchanged on the channel of the piconet: all packets sent in the 
same piconet are preceded by the same channel access code. 
In the receiver of the Bluetooth unit, a sliding correlator cor- 
relates against the access code and triggers when a threshold 
is exceeded. This trigger signal is used to wake up the entire 
signal processing of the receiver. In addition, it is used to fix 
the receive timing. The correlator remains active during the 
entire search window: when a new correlation value is found 
which is larger than a previous correlation value which initially 
triggered the receiver, the entire receiver is reset and triggered 
again. The channel access code consists of a preamble, a sync 
word, and a trailer, see Figure 5. Both preamble and trailer are 
fixed bit patterns. 
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Figure 5: Channel Access Code 

. The preamble is. a 'fixed zero-one. pattern of. 4 symbols used, 
to facilitate DC compensation. The sequence is cither 1010 or 
0101. depending on whether the LSB of the following access 
code is I orO respectively. The sync word is a 64-bit code and 
is derived from the master's lower address part (LAP) of its 4S- 
bit unique address. The code guarantees large Hamming dis- 
tance between sync words based on different addresses. In ad- 
dition, it has good auto- and cross-correlation properties which 
improves the liming synchronization process. Like the pream- 
ble, the trailer is a fixed zero-one pattern of four symbols used 
for line compensation. The sequence is either 1010 or 0 101 
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depending on whether (ho MSB of the sync word is 0 or I 
respectively. 
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Figure 6: Header format 

The header, shown in Figure 6, contains lower-level link 
control information. It consist of 6 fields: a 3-bit sub ad- 
dress (Mj\DDR). a 4-bit packet type (TYPE), a 1-bil How 
control bit (FLOW), a I -bit acknowledge indication (ARQN). 
a 1-bit sequence number (SEQN). and an 3-bit header error 
check i HEC). The total header information consists of 1 8 bits, 
but is protected with a 1/3 forward-error correction coding re- 
sulting in a 54-bit header length. 

M_ADDR: This field represenis a member address used to 
distinguish the active participants on the piconet. With the 
M.ADDR. the master can separate the different slave active 
on the piconet This M.ADDR is assigned temporarily to a 
unit for the time it is active on the channel. Packets exchanged 
between the master and the active slave all carry the M_ADDR 
of this slave. The all-zero address is reserved for broadcasting 
purposes. Slaves in the PARK mode are inactive but are still 
locked to the FH channel. The parked slaves do not use an 
M_ADDR but their full 48-bit unique address. 

TYPE: Sixteen different types of packets can be distin- 
guished. The 4-bit TYPE code specifics which packet type is 
used. Important to note is that the interpretation of the TYPE 
code depends on the physical link type associated with the 
packet. First, it shall be determined whether the packet is a 
SCO or an ACL packet. Then, it shall be determined which 
of the SCO packet types or ACL packet types we arc dealing 
with. The TYPE code also reveals how many slots the current 
packet will occupy. This allows the non-addressed receivers to 
go to sleep for the duration of the occupied slots. 

FLOW: This bit is used for How control over the ACL link. 
When the RX buffer for the ACL connection in the recipient 
is lull and is not emptied by the link support unit, a STOP 
indication (FLOW=0) is returned to stop the transmission of 
data temporarily. Note, that the STOP signal only concerns 
ACL packets. Packets including only link control (POLL and 
NULL packets) or SCO packets can still be received. When 
the receive buffer is empty, a GO indication (FLOW=l ) j s re- 
lumed. When no packet is received or the received header is 
in error, a GO is assumed implicitly. 

ARQN: This is an acknowledge field to inform the sender 
whether the reception of the packet in the preceding slot was 
successful (ARQN=1 ) or unsuccessful ( ARQN=0). When no 
valid ARQN held is received. ARQN=0 is assumed implicitly. 
ARQN=0 is the default value. The ARQN is piggy-backed in 

Mobile Computing and Communication* Rcvnnu, Volume 2, Number - 



the return packet. The success of the reception is checked by 
means of a cyclic redundancy check (CRC) which is added to 
each pay load that contains data. An unnumbered ARQ scheme 
is used which means that the ARQN relates to the packet just 
received. 

SEQN: This is a numbering held to distinguish new packets 
from retransmitted packets. The SEQN bit is toggled for each 
new packet transmission. A retransmitted packet keeps the 
same SEQN bit. If two consecutive packets are received with 
the same SEQN bit, the second packet is ignored. 

HEC: Each header has a header-error-check to check the 
header integrity. The HEC consist of an S-bit word generated 
by the polynomial 647 (octal representation). Before generat- 
ing the HEC. the HEC generator is initialized with the 8-bit 
upper address part (UAP) of the master identity. The HEC is 
then calculated over the 10 header bits. Before checking the 
HEC, the receiver must initialize the HEC check circuitry with 
the proper 8-bit UAP. If the HEC fails, the entire packet is dis- 
carded. 

IILG. Packet types 

The 4-bit TYPE code in the packet header specifies 16 differ- 
ent packet types. The packet types have been divided into 4 
segments. The first segment consists of 4 packets and is re- 
served for control packets common to all physical link types. 
The second segment consists of 6 packets and is reserved for 
packets occupying a single time slot. The third segment con- 
sists of 4 packets and is reserved for packets occupying three 
time slots. The fourth segment consists of 2 packets and is 
reserved for. packets occupying five time slots. The slot oc- 
cupancy is reflected in the segmentation and can directly be 
derived from the type code, fable 1 summarizes the packets 
defined for the SCO and ACL link types. 

At this moment, four different SCO packets have been de- 
fined. So far. only single-slot packets have been defined. SCO 
packets are typically used for synchronous information like 
voice. The packets differ in the amount of FEC coding ap- 
plied and whether part of the packet is reserved for data as 
well as voice. For the ACL link. 6 different packet types have 
been defined. They differ in the in the amount of data carried, 
in the presence of absence of FEC coding, and whether ARQ 
is applied or not. 

hline 

III.HL Error correction 

There arc three error-correction schemes delined for Blue- 
tooth: 1/3 rate FEC. 2/3 rate FEC. and an ARQ scheme for . 
data. The purpose of the FEC scheme on the data pay load is to 
reduce the number of retransmissions. However, in a reason- 
able error-free environment. FEC gives unnecessary overhead 
that reduces the throughput. Therefore, the packet definitions 
given in Section III.G have been kept flexible to use FEC in 
ihc payload or not, resulting in the DM and Dl I packets for the 
ACL link and the HV packets for the SCO link. The packet 
header is always protected by a 1/3 rale FEC; it contains valu- 
able link information and should survive more bit errors. 



Tabic 1: Packets defined lor SCO and ACL link types 
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IILL Speech coding 

In the Bluetooth system, two speech coding schemes are sup- 
ported. Continuous Variable Slope Delta (CVSD) Modulation, 
and logarithmic Pulse Coded Modulation (logPCM), both op- 
erating at 64 kbits/second. The default speech coder is the 
more robust CVSD coder. 

The CVSD coder is a waveform coder applying a delta mod- 
ulation scherne[5]. To reduce slope-overload effects, syllabic 
companding is applied: the delta step size is adapted accord- 
ing to the average signal slope. The interface to the CVSD 
speech coder is 8000 samples/second linear PCM. The CVSD 
degrades gracefully in a noisy environment. Increasing inter- 
ference is experienced as a growing background noise. 

The alternative speech coding is basic iogPCM. The 16-bit 
linear PCM at 8000 samples/second is compressed lo 8-bit log- 
PCM at S000 samples/second using A- law or /t-law compres- 
sion. 

III.J. Authentication and Privacy 

In order lo provide user protection and information secrecy, the 
system has to provide security measures both ai the application 
layer and the physical layer. These measures shall he appropri- 
ate for a peer environment. This means that in each Bluetooth 
unit, the authentication and encryption is implemented in the 
same way. Bluetooth specifies a base level encryption, which 
is well suited for silicon implementation, and an authentica- 
tion algorithm, which also provides devices which don't nec- 
essarily have host processing capabilities a level of security. 
In addition, future ciphering algorithms can be supported in a 
backwards compatible way using version negotiation. 
The main features are: 

• Challenge-response routine for authentication 

• Session key generation. Session keys can he changed ai 
any time during a connection 

• Stream-cipher 
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Entity 


Size 


Bluetooth address 


48 bits 


private user key 


64 bits 


RAND 


128 bites 



In general security problems, three entities are used: a pub- 
lic entity # which is unique for each user, a secret entity, and a 
random entity which is different for each new transaction. The 
three entities and their sizes as used in Bluetooth are summa- 
rized in Table 2. 

The Bluetooth address is 48-bits in length and unique for 
each Bluetooth unit. Bluetooth addresses are publicly known, 
and can either be. obtained via Man-Machine interactions 
(MMI), or automatically via an inquiry routine. The user key 
is a 64-bit secret key which is derived during initialization but 
is further never disclosed. The RAND is a random number 
which will be derived from a pseudo-random process in the 
Bluetooth unit. 

IV. Other Wireless Initiatives 

This section describes the history and focus of several other 
wireless industry groups and compares their vision and goals 
to those of the Bluetooth SIG. 

IV1A. IrDA (http://www.irda.org/) 

The Infrared Data Association (IrDA) is a non-profit corpora- 
tion established in 1993 to set and support hardware and soft- 
ware standards for infrared communication links. The IrDA 
protocol stack is designed to support usage models similar to 
those of Bluetooth. Legacy serial-cable-oriented applications 
are supported via cable emulation while new IR-specirie APIs 
support the development of applications able to take advantage 
of the full capabilities of. the IR link management and trans- 
port protocols. There are already IrDA-compiiant interfaces 
on many printers, handheld computers, notebook computers, 
and digital still image cameras. The advantages of IR over 
RF include reduced cost, lower standby power, higher band- 
width, and less regulations governing global use. The most 
significant disadvantage of IR is the line-of-sight restriction 
that constrains Bluetooth s vision of hidden and unconscious 
computing. 

The Bluetooth SIG believes in promoting the development 
of applications thai work over either IR or RF. The applica- 
tion developer, and especially the user, should not care what 
physical medium is used. To achieve this, the Bluetooth SIG 
is working on interfacing with the higher- level IrDA protocols 
and has approached the IrDA to achieve interoperability across 
both wireless media. 

IVB. IEEE 802.1 1 (http://www.ieee.org/) 

The IEEE 802.1 1 standard dclines RK and IR physical lay- 
ers. Media Access Control (MAC) layer for LAN connectivity 
and additional access point and security protocols. Generally 
speaking, IEEE 802. 1 I defines a larger set of physical layers 
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'consisting of two radio solutions (frequency hopping and di- 
rect sequence) and an IR solution while Bluetooth uses a fast 
frequency hopping radio solution. Regarding the MAC layer. 
Bluetooth uses a connection-oriented TDM A scheme while 
IEEE 802. \ I uses a carrier sense multiple access with collision 
avoidance ( CSMA/CA > scheme. The goal of IEEE 802.1 I is 
enabling LAN based applications with a larger radio coverage 
while Bluetooth *s paradigm is enabling wireless connectivity 
between diverse types of devices including an access point to 
a wired LAN in a piconet environment. Finally, IEEE 802. 1 I 
has been recently considering a short range solution similar to 
the Bluetooth under its PAN working group. 

rV.C. HomeRF (http://www.homerf.org/) 

The HomeRF 5 Working Group (HRFWG) is developing 
an open specification targeting the home environment [6]. 
HomeRF focuses on both stand-alone and wireless extensions 
to home networking technologies. In its current draft, the 
HomeRF specification defines an air protocol based on a com- 
bination of CSMA/CA for data and cordless telephony [1] 
technology for voice. On the voice side, HomeRF uses an 
ADPCM coding at 32 Kbps compared to Bluetooth's more 
robust CVSD coding at 64 Kbps. However, HomeRF. does 
have the ability to retransmit a voice packet while Bluetooth 
never retransmits voice. Another distinguishing factor is all 
HomeRF voice traffic is channeled through a ' control point" 
while Bluetooth *s voice traffic, like the data traffic, uses ad 
hoc connections between any two Bluetooth units. On the data 
side. Bluetooth views HomeRF as a relaxed version of IEEE 
802.1 1. 

V. Summary 

By developing the Specification for a low-cost, low-power 
radio-based cable replacement, the Bluetooth SIG hopes to 
drive an evolution in personal networking. In this article, we 
have shared some of the vision, challenges, and architecture 
the SIG is contemplating. For more information, readers are 
encouraged to explore http://wvvw.bluetooth.com. 

By the time of this publication, the first release of the Blue- 
tooth Specification (0.6) will be available to SIG members for 
review and comments. The release of the Bluetooth Specifi- 
cation 1.0 is planned lor the first quarter in 1999 and products 
compliant to that Specification are expected in late 1999. 
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